這個標題有點重複，因為說白了「全端」工程師就是「懂很多」的工程師。

這類工程師受到市場青睞，說白了就是因為專案在管理上認為「程式設計不用有巧思，只要有足夠的工作量能與效率就是合格的工程師」。

但這種思維很矛盾，因為沒巧思的東西無法造就技術進步或優勢，久了專案管理就是指望工程師真的動作夠快、工作量夠多夠穩定、同時又便宜，然後讓專案在「勞力」上有競爭優勢而已。

跟一般的「懂很多」相比，「全端」哪裡不好呢？（「是否有巧思」是個很難客觀論證的答案。）

舉實例吧！

像：今天APP有多項API傳輸需求，正常的Mobile工程師會用「介面」去制定一個傳輸資料的框架，只留下「設定要傳輸的資料」和「反映得到的回傳」的兩個接口。

interface API{
  void feedMeData(String url, String postOrGet, HashMap<String, String> data);
  String feedYouReturn();
}

但有全端工程經驗的工程師（未必自詡為全端工程師）經常寫出這樣的物件...

class API{

  void sendAPI_login(String id, String pwd){...}
  void sendAPI_userData(String userName){...}
  void sendAPI_publicMessage(String date1, String date2){...}
  .......
}

曾經見識過專案最後走到「API class竟然比每個CustomActivity class都還要巨大」的地步！

而且不只一次。差別只是「API class比CustomActivity class大幾N倍」、還有工程師在其他地方（演算法、資料結構等事情上）展現的技術差異。

所以並不是說「全端工程師技術差」，（我看過全端工程師用很驚人的演算法去動態生成各種UI，）只是他們經常缺乏幫Mobile專案架構優化的經驗與思維，結果會不知不覺把Mobile當Server在寫，最後...專案規模可能會在工程上無法擴張，因為新來的「非全端」工程師根本無法跟這位工程師合作，（所以招募來的人一直離職，）後續要維護要升級要擴充，成本高、效率差......種種技術問題讓專案的商業價值變差，最終專案就死掉了。